1. Field of the Invention
The embodiments described herein are generally directed to the field of information technology (e.g., with features of network switching, routing, proxying, and database technologies), and, more particularly, to the detection of security threats and breaches by analyzing traffic between database servers and their clients, web servers and their clients, and/or in technologies other than structured data storage systems, such as directory protocols, Hypertext Transfer Protocol (HTTP), email traffic, etc.
2. Description of the Related Art
Over the last few decades, structured—and, in particular, relational—database technology has become a critical component in many corporate technology initiatives. With the success of the Internet, the use of database technology has exploded in many consumer and business-to-business applications. However, with the popularity of database architectures, new risks and challenges have arisen, such as complex and difficult-to-identify performance issues and subtle gaps in security that can allow confidential data to be access by unauthorized users.
A very common practice is to use a three-tiered architecture to implement applications, as illustrated in FIG. 11. While FIG. 11 depicts only a single web server 1110, application server 1112, database server 1114, and client 1130, it should be understood that it is common to have multiple servers 1110, 1112, and 1114, directly or indirectly, connected to multiple clients 1130. A client browser on a client 1130 provides an end user an access point to the application via one or more networks 1120 and web server 1110. Common applications include online storefronts, banking access, medical records, and the like. In many cases, an application, such as a mobile application, replaces the web browser, but the protocols and operations of the application are very similar. Web server 1110 parses and processes requests received from client 1130 and returns results to client 1130 over network(s) 1120, which may include the Internet. Application server 1112, communicatively connected to web server 1110, contains the core (e.g., business) logic of the application. Application server 1112 uses the resources of one or more database servers 1114 to store and query persistent state needed by the application, such as account information, including, for example, account balances, purchasing information, payment information, shipping information, and/or the like. Web server 1110, application server 1112, and database server 1114 are often communicatively connected via one or more internal networks, but it should be understood that they could be connected in other manners (e.g., via external network(s), direct connection, etc.).
Application server 1112 may make requests to retrieve, summarize, or change data stored by database server 1114 using Structured Query Language (SQL). SQL is a special-purpose language designed for managing sets of data stored in tables that may be related to one another using relational algebra and tuple relational calculus. It is primarily a declarative language, but current commercial implementations extend it with procedural scripting elements. Application server 1112 converts HTTP requests into SQL requests that retrieve or query data.
Practical applications limit the types of operations an external user may request, but ultimately the applications must generate SQL that expresses some aspect of one or more application operations to database server 1114. Applications may generate SQL using a variety of techniques. Typically, there are a set of SQL templates that are specialized with the user request data and then submitted to the database server.
A very common security flaw is for application server 1112 to allow some unanticipated portion of the external HTTP request to be aggregated with the generated SQL, causing the semantics of the SQL statement to no longer match the application's intent. This may allow unauthorized extraction or modification of data on database server 1114. This is referred to as SQL injection and can be responsible for significant data loss. An unauthorized modification to the database server state is also possible, allowing an attacker to not only change the data in the database but to cause execution of arbitrary program code on database server 1114. This code may, in turn, open additional security vulnerabilities in the application by providing a tunnel through security screens for the attacker to gain further unauthorized access.
FIG. 12 illustrates an example of SQL injection. Statement A represents an example SQL query that the application designer expected to be run. Specifically, a username “joe” and password “xyzzy” are checked against a database table “USERS” to determine if the user should be granted access to the application. However, an attacker may enter the string “OR 1=1—” as the username, instead of “joe” or some other valid username, which results in the application generating the SQL query in Statement B. This effectively changes the semantic meaning of the statement. Specifically, the query will always return a “1” regardless of the password entered, since “1” will always “=1” and the portion of the query that performs the password check (i.e., “AND PASSWORD=‘xyzzy’”) is commented out with the “—” token. Thus, the injected SQL allows the attacker access to the application even without knowledge of a valid username or password. There are many methods to trick application server 1112 into passing this manner of attack through to database server 1114. So many, in fact, that it is very difficult for an application designer to implement an application that prevents all such attacks.
Denial-of-service attacks may also be perpetrated on the database via direct SQL injection techniques or via more subtle parametric changes. In either case, such techniques or changes can be used to cause database server 1114 to use an unusually large amount of its limited resources in too short of a timespan. Furthermore, database denial-of-service attacks can render database server 1114 useless with only a handful of packets spread out over a long period of time. Thus, since this type of attack does not require a large amount of network traffic to mount, it is difficult to detect using traditional methods.
Many simple toolkits that probe for SQL injection vulnerabilities are available for free or at a cost. However, available toolkits do not provide the application or its operators any direct way to detect when they are being victimized by an SQL injection attack. Thus, the application will not realize it has issued hostile commands to database server 1114, and database server 1114 has no way to know when the commands that it is receiving are unauthorized.
Unauthorized access may be detected based on an access not matching the usual source (e.g., location, Internet Protocol (IP) address, etc.), user credentials, time or date of the access, and the like. Specific tables or columns in the database being accessed from an unusual source or user, at an unusual time or date, and/or in an unusual way (e.g., changing an object which is normally only read) constitute another form of security threat. The response database server 1114 provides to a given request varies, but aspects of the response—such as the number of rows returned or an error being returned—may also indicate unauthorized activity.
Existing systems that attempt to perform these functions are plagued with a very high number of false-positive threat indications. This makes them unusable in practice.